home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0013.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  3.4 KB  |  69 lines
  1. Hi,
  2.  
  3. First of all I'd like to say that I really appreciate that you released
  4. the sources for DVIEW. I've read about DOOM type rendering for quite a
  5. while, but to actually study working code was wonderful. Many thanks!
  6. You really should avertise that code more in rec.games.programmer. Every
  7. other day there's another person asking questions that are all answered
  8. quickly by a look at your work.
  9.  
  10. The reason I started looking deeper into this field was that I and a couple
  11. of other people on the internet decided to see if it was possible to write
  12. a DOOM compatible game for the Atari Falcon030. As the name suggests the
  13. machine is running a Motorola 68030, in this case at 16MHz with a 16 bit
  14. data bus. The CPU itself will of course have no chance of handling DOOM,
  15. but there's also a M56001 DSP, which we hope to use extensively.
  16.  
  17. The port of DVIEW to the Falcon took only a couple of hours, but in its
  18. current form it's not very useful. Compiled with maximum optimizations,
  19. using GNU C++, a staggering 2.5 frames/second average was reached...
  20. Now, putting all the rendering code on the DSP would of course improve
  21. the frame rate tremendously, but there is one major problem with that:
  22.  The DSP only has 32kword (24 bit) of memory
  23.  (there is a two-way DMA channel at somewhere around 1Mbyte/s as well)
  24. So, the wallrun, intersections and floorlist arrays won't fit.  :-(
  25.  
  26. I managed to eliminate the arrays mentioned above by drawing all walls
  27. and floors as soon as they were available, which most often works rather
  28. nicely. The main problem is that floors behind doors are drawn after the
  29. door itself, but I think it'll be possible to handle that somehow.
  30.  
  31. While this all appears to be quite fine at the first look, I've begun to
  32. worry about the continuation of the project. It seems to me that the
  33. inserting of the sprites into the environment will be extremely difficult.
  34. Before the arrays were removed, there was some information that could
  35. perhaps be used to determine what the sprites should be clipped against,
  36. but now that's not there anymore.  :-(
  37.  
  38. So, a couple of questions:
  39. - Have you given any though as to how sprite clipping would be handled?
  40. - Have you done anything else on the program since you released it?
  41. - Any ideas on what could be improved/optimized?
  42. - Do you know if anyone else is using the sources?
  43.  
  44. Finally a couple of bug reports:
  45. - For some of the load routines the calculation of the number of
  46.   structure items to load is less than perfect (negative results can occur).
  47.   The (short) typecast is in the wrong position.
  48. - You may have noticed that there are sometimes very strange distortions
  49.   near the 'front'. I've traced this to the first of your clippings, the
  50.   one where you clip to an x=z line.
  51.   If you remove that clipping completely, everything works nicely.
  52.   Was there a reason for the clip?
  53.   If so, why only clip the 'from' coordinates and not the 'to' ones (or
  54.   perhaps it was the other way around)?
  55.  
  56. By the way, the maze looks much better if you let the name of the textures
  57. used set the colours (I XOR the characters in the name right now, but a
  58. more sophisticated algorithm would be better).
  59.  
  60. Regards,
  61. Johan
  62.  
  63. -- 
  64.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  65.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  66.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  67.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  68.  
  69.